why two lower bounds?

That's a test cases which should fail

ah, I see, to check they are not accepted :-)

I tried to make this even more accurate but I seem to have hit a limitation of shat SHACL can do when there are multiple properties with same value. I failed to make a validation to catch for example

 sh:minInclusive <https://ld.admin.ch/time/year/2020>
 sh:minExclusive <https://ld.admin.ch/time/year/2020>

I could not find a simple enough way to include this in the validation shape

I tried to make this even more accurate but I seem to have hit a limitation of shat SHACL can do when there are multiple properties with same value. I failed to make a validation to catch for example

 sh:minInclusive <https://ld.admin.ch/time/year/2020>
 sh:minExclusive <https://ld.admin.ch/time/year/2020>

I did not define a class for the annotation context so this is needed to distinguish them from actual key dimension because sh:path/^sh:path will find both. Would not have been needed if we used a different property to refer to the dimension in annotation context.

@tpluscode it would be helpful for the reader to explicitly state lower limit values and upper limit values 😉 as there are also situations where only one sort occurs and this information is needed to check and display whether the values are within the acceptable range.

Good catch. We seem to have dropped that along the way - or at least I think we had that covered once.
In any case, we should include that somehow.
Either with different classes? I.e. meta:UpperLimit and meta:LowerLimit? Or maybe more elegant with schema:minValue/schema:maxValue instead of the generic schema:value?

Or would you see a case where a LIMIT could no specified to be an upper or lowr Limit @Rdataflow ? It would not really be a limit without that specification?

After a small chat with @Rdataflow, we both agree that the generic schema:value is not well suited for meta:Limit. At least for what we try to express here.

One thing we should distinguish is between the mathematical concept of a limit (or limes) and limit as we envisioned here. Here, we think about something like a speed limit. Or some value, which should not be exceeded (or exceedence leads to some consequence), or below which a measurement can't be quantified like a detection limit.

We would argue, that these kinds of limits do generally have an upper or lower meaning associated with them. So the use of schema:value can be and should be replaced with schema:minValue and/or schema:maxValue, to make the meaning of this limit clearer.

Edit: wrote schema:minInclusive which of course was rubbish, my bad. Replaced it with schema:minValue.

@Kronmar-Bafu I do not follow, which part is in your opinion missing from the spec? The snippet shows schema:limit but it also says that minValue/maxValue can be used.

@tpluscode IIUC this shacl will allow single upperLimit w/o lowerLimit, correct? 🤔 - which is what @Kronmar-Bafu expects 👍 in order to allow logical checks if values are exceeding the limit ... and style charts accordingly.

i.e. emission limits typically are of kind upperLimit - emssions are expected to stay below

Here, this part, schema:value is too generic. Do we mean a lower or an upper limit?

We can avoid this confusion in at least three ways I could think of:

1. Introduce two new classes meta:UpperLimit and meta:LowerLimit
2. Add some other specification, like an additional meta:limitType "upper" or something like that
3. Be clear, on what we mean, by replacing schema:value by something more precise, like a schema:maxValue for an upper limit or a schema:minValue for a lower limit.

I would advocate together with Thomas for option three, as it reuses schema:maxValue/schema:minValue instead of introducing new things.

Ok, I think I understood now.

Let me clarify one more point. Would it ever make sense to have both schema:minValue and schema:maxValue on a limit. From what you write, I guess that is pointless?

Depends on how you want to look at it.

It could be, that something is supposed to follow an upper and a lower limit. One could then add a schema:minValue as well as a schema:maxValue to the same meta:Limit. Or be more precise and add two meta:Limit.

From a semantic's point it might be clearer to add two meta:Limit in such a case. So yes, there's not really a point to have both predicates for one meta:Limit. Or would you like to disagree @Rdataflow ?

I just imagined the case of a target range, being specified by means of lower and upper limit. Yes, for such cases it could make sense to have both at the some node ;-)

Two thoughts:

1. It could make sense to have min and max, together, so to allow multiple "limits" with corresponding upper and lower limit. (e.g. Target Band 2025, Target Band 2026) so I propose to keep connected min / max together.
2. It should be possible, to give a limit annotation a title, and probably also a sub-title/description. There might be multiple limit annotations, and earlier or later even a possibility to choose one, or multiple to show in an interface (e.g. visualize).

Alright, you got me conviced. I was steering more towards thinking of target ranges as "two limits in a trenchcoat" and thus wanting to split them up. But that would just be more "wordy". So let's keep the possibility.

As for your second thought @l00mi , I agree. a dcterms:title would make sense.

In principle, any property is allowed. The shapes aren't closed. Do you think it's worth mentioning that explicitly in the spec?

#206
@Kronmar-Bafu @Rdataflow

This sh:property could be removed if on decides on dropping schema:value in favor of schema:minValue/schema:maxValue.